Hello @jaimet ,

yes this looks like a packaging problem. The problem is that the libpython was linked with glibc 2.35 on ubuntu-22.04, but the code is run on debian bullseye with glibc 2.31. Glibc of course does not guarantee backward compatibility, so the dynamic loader fails because new symbol versions in 2.35 are not available in 2.31. The problem is that esptool github build workflow uses ubuntu-latest(22.04) runner and pyinstaller does not pack glibc libraries.

This is easily reproducible

[12] Error loading Python lib '/tmp/_MEI265mQ2/libpython3.8.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.35' not found (required by /tmp/_MEI265mQ2/libpython3.8.so.1.0)

One solution would be to somehow force the pyinstaller to pack also libc libraries for esptool, but I'm not sure if this could be easily done. Other possibility is to use some older ubuntu runner and make it clear that the pyinstaller one-file package requires at least a specific glibc version installed on the system where it's used.

There is a github ubuntu-20.04 runner which has glibc 2.31 and using it seems to solve this problem. At least for the current debian stable distro.

I quickly tried this in my esptool fork with the current version on master branch and the generated pyinstaller package is working for me on debian 11

The following patch should hopefully fix this problem, but maybe there is a better solution.

Thank you very much for reporting this.